An Application Programming Interface (API singular, APIs plural) refers the method or procedure by which one computer program can use the functionality of another program, or by which a user and request (invoke) execution of a service according to his or her wishes. For example, a spreadsheet application program running on a personal computer may need to access a database program in order to retrieve certain data from it. In order to do so, the spreadsheet program must be programmed in a manner which allows it to invoke or “call” the database program, which would include a variety of control parameters (e.g., “arguments”) which indicate to the database program what information is requested by the spreadsheet program. These control parameters may include the database file name, if known, and search or filter parameters, for example, a range of customer names, transaction dates, transaction amounts, etc. In another context, a user may wish to update his or her “status” statement on a social networking web account, so the user may have to operate a sequence of functions such as logging in, authenticating, selecting “status”, then selecting “edit”, then typing in the status text, and then clicking “post”.
API often are “published” or made known to other programmers using a syntax which includes mandatory or required arguments and optional arguments. Some APIs are “exposed” to other programs so that other programs may discover their existence and make use of their offered functionality. Most API are also dependent on operating system (OS) details, so an API for a database program running on a first OS may be different than the API for the same database program running on a second OS. Similarly, different revisions of the same program product may have different APIs, because new features may require the addition of mandatory or optional arguments in order to exercise those features.
Some APIs conform to open or consortium-developed “standards”. Such APIs allow programs developed by different suppliers to interoperate with a high degree of certainty that the interface will be successful. However, historically, such standardized API only encompass a least common denominator of features and functions, and often do not include any feature or functions which are unique or specific to just one vendor's product. It is in these different functions that the vendors provide competitive product features, so many products offer both standardized and “extended” APIs, where the unique functions are requested via the extensions to the standardized API. As a result, if programmers of a new product which their program to be independent and compatible with all suppliers of a particular program type, such as databases, they will restrict themselves from using any non-standard API extensions, but this has a cost in that they are unable to use any of the sometimes very effective proprietary functions of some of the available products.
Still other API are entirely proprietary, and sometimes are confidential or secret in nature. For example, in order to write programs which will interface to certain high-value target programs, such as stock trading systems, the programmer must first obtain permission from the API owner to get the details of the proprietary API, which usually involves some degree of certification of the API user as a non-threat and a non-disclosure agreement to maintain the confidence of the API.
For programmers, the result is a landscape of proprietary, standardized, and extended API for software developers to use, which will accelerate their time-to-market by leveraging existing program functionality from other programs and remote services. As the API are constantly updated, revised, and created, programmers face a considerable challenge to remain aware of the most recent versions of each API.
For users, the problem is similar to that of the programmers, in which a user may become frustrated trying to figure out how to accomplish similar, simple tasks (e.g., status update, balance inquiry, etc.) on multiple online services, each of which has a different user interface sequence to accomplish the same operation. Even after learning these sequences, the user may be frustrated by the smallest of changes or updates to the user interfaces. Thus, tools to integrate or provide a “dashboard” into multiple online services of the same type, such as a social networking dashboard or a financial management tools dashboard, are becoming popular, which abstract the user from needing to know all the specifics of each online account to accomplish the same actions.